The Transmission Control Protocol (TCP) remains the most widely used transport control protocol across the Internet today. Although TCP was initially designed and optimized for wireline networks, such protocol is increasingly being used over wireless networks primarily due to the growing popularity of wireless data applications being offered by wireless service providers to their subscription base. The primary objective of TCP is to efficiently use the available bandwidth across the network and to prevent overloading the network (and the resulting packet losses) by appropriately throttling the sender's transmission rates. In conventional wireline TCP networks, network congestion is typically identified as the main underlying cause for packet losses.
In contrast, packet loss in wireless networks may occur for other reasons, for example, related to the time-varying nature of the wireless communications channel and the mobility of the end user. That is, as is well-known, channel fading and “dropped” calls as mobile subscribers move about (requiring handoffs between base stations supporting the wireless network) are common occurrences which contribute to the overall quality of service delivered by a wireless service provider. As a consequence of such variable packet loss circumstances in wireless networks, TCP may interpret such packet losses due to transmission errors, high latency and/or delay variability, as indications of network congestion. Unfortunately, this misdiagnosis of the root cause of packet losses will result in the TCP layer reducing the sender's transmission window and the initiation of well-known congestion control mechanisms (which are not required). As such, many wireless networks aim at avoiding packet losses at the TCP layer by implementing robust link layer protocols (e.g., using error control coding and robust link adaptation) as well as soft handoff and seamless mobility management algorithms. However, such solutions increase the packet transmission delay and its variability, and may have adverse effects on the TCP behavior.
In addition to the packet loss issues impacting TCP applications in wireless communications networks, so-called “delay spikes” affect the TCP through timeouts and throughput. As used herein, delay spikes are defined as a sudden and significant change in the round-trip time between a TCP sender and its TCP receiver. High delay variability has been observed in wireline networks and can be caused by so-called “route flipping” (see, M. Allman et al., “On Estimating End-to-End Network Path Properties”, in Proceedings of ACM SIGCOMM, September 1999, which is hereby incorporated by reference herein). In wireless networks, the delay variability is attributable to several factors, most notably the time-varying quality of the wireless link (both the inherent variability and the variability induced by terminal mobility). Other contributors to delay variability in wireless networks include: (a) handoff delay caused when users are transferred between transmitting and/or receiving base stations; (b) transmission interruptions due to priority scheduling; and (c) preemptive service. In terms of the growth projections in wireless communications, transmission interruptions and service preemptions are becoming increasing important as wireless networks increasingly introduce multimedia applications thereby requiring efficient scheduling algorithms to maintain quality of service guarantees.
Thus, the observation and measurement of delay spikes has garnered particular attention and study, see for example, A. Gurtov et al., “Multi-layer Protocol Tracing in a GPRS Network”, in Proceedings of the IEEE Vehicular Technology Conference, September 2002; J. Korhonen et al., “Measured Performance of GSM HSCSD and GPRS”, in Proceedings of the IEEE Conference on Communications, June 2001; and M. Yavuz et al., “TCP Over Wireless Links with Variable Bandwidth”, in Proceedings of the IEEE Conference Vehicular Technology Conference, September 2002, each of which is hereby incorporated by reference herein. The effects of large delays and delay variability on the behavior of TCP have been investigated, for example, in S. Fu et al., “Effect of Delay Spike on SCTP, TCP Reno and Eifel in a Wireless Mobile Environment”, in Proceedings of International Conference on Computer Communications and Networks, October 2002; and A. Gurtov, “Effect of Delays on TCP Performance”, in Proceedings of IFIP Personal Wireless Communications, August 2001, each of which is hereby incorporated by reference herein. Further, sudden increases in delay variability have been shown to lead to spurious TCP timeouts and the following undesirable responses: (a) TCP interprets a timeout as being caused by packet losses and unnecessarily retransmits the packets that are presumed lost; and (b) triggering of congestion control and a false reduction in the TCP window size, thereby contributing to lower throughput (see, R. Ludwig et al., “The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions”, in ACM Computer Communication Review, volume 30, No. 1, January 2000, which is hereby incorporated by reference herein).
In view of such delay variability issues, several techniques have been proposed to alleviate their affect on TCP performance. For example, TCP Eifel (see Ludwig et al. supra.) has been proposed to detect spurious timeouts as well as spurious retransmits through the implementation of time stamping at both the sender and receiver. However, this technique requires an additional 12-byte overhead in the TCP header and has not yet been widely deployed. Other potential mitigation techniques for delay variability are described in A. Gurtov, “Making TCP Robust Against Delay Spikes”, University of Helsinki, Department of Compute Science, Technical Report C-2001-53, November 2001, which is hereby incorporated by reference herein. These techniques include timing every transmitted segment (instead of timing a single segment per window of outstanding segments) and restarting the retransmit timer when a segment is retransmitted or upon reception of a duplicate acknowledgement.
Additional techniques are proposed in A. Gurtov et al., “Responding to Spurious Timeouts in TCP”, in Proceedings of IEEE INFOCOM, March 2003, which is hereby incorporated by reference herein, and include enhancing the TCP Eifel for a more efficient operation in the presence of packet losses, appropriately restoring the congestion control mechanism and adapting the retransmit timer to avoid further spurious timeouts. While the above-described techniques provide for some level of alleviating the affect of delay variability on TCP performance, it is important to note that each of these solutions requires some degree of modification to the TCP protocol itself which may not be widely available. Further, these solutions do not attempt to avoid spurious timeouts but rather change the reaction of TCP when such timeouts occur. Moreover, some of the solutions, such as split-TCP solutions using proxy mechanisms, interfere with the end-to-end nature of the protocol paradigm. The end-to-end nature of the protocol is important to ensure reliable delivery of data from the source to the end-destination as well as for security reasons and end-to-end encryption of the data.
The above-cited U.S. patent application Ser. No. 09/665,724 discloses a wireless data transmission technique which employs the introduction of a delay into the communication channel so as to increase the deviation from the average in the channel delay thereby increasing the length of time required for a TCP timeout to occur. However, while this technique offers certain advantages and improvements in avoiding timeouts, an issue that still may arise is ensuring unobtrusive implementations in terms of TCP protocol access and interference with the TCP paradigm.
More particularly, the above-cited U.S. patent application Ser. No. 09/665,724 proposes to introduce the additional delay at either the mobile terminal or the mobile base station in an effort to minimize the number of spurious timeouts experienced by a TCP connection. In such an approach it will be noted that wireless networks run a series of different protocols, which are stacked onto each other in the well-known protocol stack. One of those layers is the transport layer at which TCP operates. TCP typically transmits data segments containing a certain amount of information bits. The communicating entities at the TCP layer are the TCP server (at the sending side) and the TCP receiver (at the receiver side). As will be well understood, these entities would typically correspond to mobile terminals, web servers, databases or file servers, to name just a few. Other well-known protocols operating at the layers below TCP, such as the Internet Protocol (IP), the Radio Link Protocol (RLP) or the Radio Link Control (RLC) protocol, fragment TCP segments into smaller data units (typically called frames) and operate between intermediate entities in the network, such as base stations, base station controllers, radio network controllers or mobile switching centers.
As such, these intermediate network entities do not necessarily have access to the TCP segments, but only to fragments of TCP segments. To illustrate this point, a base station or a base station controller may only have access to RLP frames and not to TCP segments. Therefore, if the additional delay is injected at the base station, it will affect RLP frames. Since TCP segments can have different lengths (depending on the application, the type of traffic—data or acknowledgment packets—or the capabilities of the intermediate routers in the IP network), the fragmentation of TCP segments to RLP frames potentially leads to a different number of RLP fragments per TCP segment. Hence, introducing delay at the base station may not lead to the desired delay when viewed at the TCP layer. In other words, the efficiency of the delay introduction depends on the level of fragmentation between the TCP and RLP protocols, which in itself depends on the type of data traffic and the TCP segment size. In addition, an application may not use TCP as a transport control mechanism but still may use RLP as a lower layer link protocol. In that case, the application does not experience spurious timeouts and therefore the corresponding traffic should not be subject to delay injection. However, if the delay injection is implemented at the RLP layer at the base station, the injection module cannot differentiate between RLP frames derived from TCP segments and RLP frames derived from other higher layer protocols such as UDP.
Further, the above-cited U.S. patent application Ser. No. 09/665,724 introduces delay to minimize the number of resulting spurious timeouts. However, the user-perceived performance, while dependent on the number of spurious timeouts, is not necessarily optimized when delay is introduced to minimize the number of timeouts. That is, the user-perceived throughput is a more direct measure of the performance and is better correlated with the user satisfaction. As is discussed in detail hereinbelow, this measure is one aspect to which the present invention is directed and on how the appropriate control parameters are chosen for obtaining optimized performance.
Therefore, it would be desirable to have a technique to eliminate the affect of delay variability (i.e., spurious TCP timeouts) on TCP behavior for optimized user-perceived performance and which is unobtrusive, does not require changes to the TCP protocol, and does not interfere with the end-to-end nature of the TCP protocol paradigm.